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(54) Video game apparatus and information storage medium for video game 



(57) A video game apparatus includes a CPU that 
detects a program control code included in a land object 
in the vicinity of a player object, and then, the CPU de- 
termines a kind of the land object. If the land object is 



"hole", the CPU executes a "hole operation" subroutine. 
Similarly, if the land object is "wall", "door" or "ladder", 
the CPU performs "wall operation", "door operation" or 
"ladder" subroutine. 
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Description 

BACKGROUND OF THE INVENTION 

Field of the invention 

[0001] This invention relates to a video game appara- 
tus and a game program memory medium therefor, and 
more particularly to a video game apparatus which gen- 
erates, and supplies to a display, an image signal to dis- 
play a player object existing on a land object in a virtual 
three dimensional space by virtue of, say, player object 
data and land object data, and to a game program mem- 
ory medium to be used therefor. 

Description of the prior arts 

[0002] In a conventional video game machine, when 
a player wishes a player object to, say, jump, the player 
presses a jump button on a controller so that the CPU 
causes the player object to jump in response to jump 
button operation. That is, when the player object is 
caused to jump over an obstacle, such as a hollow or 
hole, the player is required to press the jump button in 
timing of at a front of the hollow or hole while manipu- 
lating a move direction instructing means, such as a joy- 
stick or cross button. However, there may be a case that 
the player object be unsuccessful in jumping across the 
obstacle, as the timing may be of pressing the jump but- 
ton, or the player object position, in operating the jump 
button. That is, skillful operation with a jump button has 
been required to make the player object jump up and 
get across an obstacle. 

[0003] Meanwhile, complicated button operation has 
been needed to cause the player object to perform other 
actions than jump, (e.g. opening and closing a door or 
going up stairs, etc.). The player might be placed in dif- 
ficulty to play a game with enjoyment of game progres- 
sion because of his or her attention stick to button ma- 
nipulation. 

[0004] Such games, called action games, is becom- 
ing more difficult to play year by year. They are too dif- 
ficult for the player. In particular, there is a trend for be- 
ginners to sidestep from the games of such kind. 

SUMMARY OF THE INVENTION 

[0005] Therefore, it is a primary object of the present 
invention to provide a novel video game apparatus and 
a program memory medium to be used therefor. 
[0006] It is another object of the present invention to 
provide a novel video game apparatus which is easy for 
a player to cause a player object to operate, and a game 
program memory medium to be used thereon. 
[0007] It is another object of the present invention to 
provide a video game apparatus with which a player ob- 
ject can get over an obstacles without difficulty, and a 
game program memory medium to be used thereon. 



[0008] It is another object of the present invention to 
provide a video game apparatus wherein it is possible 
for a player object, virtual camera or the like to automat- 
ically carry out a required operation such as jumping, 
5 camera switching or the like, and a game program mem- 
ory medium to be used thereon. 

[0009] It is another object of the present invention to 
provide a video game apparatus which can effect com- 
plicate control with a simple program, and a game pro- 

'0 gram memory medium to be used thereon. 

[0010] A video game apparatus according to the 
present invention is for generating, and supplying to a 
display, an image signal for displaying a player object 
existing on a land object in a virtual three dimensional 

*s space by processing image data for the player object 
and the land object according to a program, the video 
game apparatus comprising: a player object image data 
generating means for generating player object image 
data to display a player object; and a land object image 

20 data generating means for generating land object image 
data to display a land object; wherein the land object 
image data includes a program control code; the video 
game apparatus further comprising a program control 
code detecting means to detect the program control 

25 code iarelation to a position of the player object, and an 
image changing means to cause the image signal to 
change depending upon the program control code de- 
tected. 

[0011] The program control code includes an action 
30 code to control an action of the player object, the image 
changing means including animation data output means 
to output animation data to automatically cause the play- 
er object to make an action in accordance with the action 
code. 

35 [0012] Specifically, wherein when the land object is a 
hollow or hole and the action code is "jump", the anima- 
tion data output means outputting animation data to 
cause the player object to make an action of jumping 
over the hollow or hole. 

40 [001 3] In one embodiment, the video game apparatus 
has a controller, in association therewith, including a di- 
rection instructing means to instruct a moving direction 
of the player object so that the player object is moved 
in the moving direction, the video game apparatus fur- 

4 5 ther comprising; a moving speed detecting means for 
detecting a moving speed of the player object, and a 
jump distance calculating means for calculating a jump 
distance of the player object based on the moving 
speed, the animation data output means outputting an- 

so imation data to cause the player object to make an ac- 
tion of jump according to the jump distance. 
[0014] When the land object is a wall surface and the 
action code is "climb", the animation data output means 
outputs such animation data that the player object 

ss makes an action of climbing the wall surface. 

[0015] However, when the action code is not "climb", 
a wall surface height calculating means is further com- 
prised to calculate a height of the wall surface, the ani- 
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mation data output means outputting such animation 
data that the player object makes an optimal action in 
accordance with the height of the wall surface. 
[0016] In an embodiment of the present invention, the 
program control code includes a camera control code, s 
the image changing means including a camera control 
means to control a virtual camera provided in the three 
dimensional virtual space. 

[0017] Incidentally, where the virtual camera includes 
a plurality of virtual cameras, the camera control code to 
includes a camera switching code, and the camera con- 
trol means including a camera switching means to 
switch between the plurality of virtual cameras depend- 
ing upon the camera switching code. 

[0018] Where the program control code includes a '5 
sound code, the video game apparatus further compris- 
es a sound data generating means to generate sound 
data, and a sound control means to control sound to be 
outputted from the sound data generating means de- 
pending upon the sound code. 20 
[0019] Where the sound data generating means can 
generate sound data for a plurality of ones of sound, the 
sound code includes a sound switching code and the 
sound control means including a sound switching 
means to switch the sound data depending upon the 25 
sound switching code. 

[0020] Incidentally, it is possible to control only sound 
in accordance with a program control code. In this case, 
a video game apparatus for generating, and supplying 
to a display, an image signal to display a player object 30 
existing on a land object in a virtual three dimensional 
space by processing image data for the player object 
and land object according to a program, and further sup- 
plying a sound signal to a sound output means by 
processing sound data according to a program, the vid- 35 
eo game apparatus comprises: a player object image 
data generating means for generating player object im- 
age data to display a player object; and a land object 
image data generating means for generating land object 
image data to display a land object; wherein the land 40 
object image data includes a program control code; the 
video game apparatus further comprising a program 
control code detecting means to detect the program 
control code in relation to a position of the player object, 
and a sound changing means to cause the sound signal 
to change according to the program control code detect- 
ed. 

[0021 ] Also, the video game apparatus generally uses 
a memory medium to previously memorizes a game pro- 
gram or image data. A memory medium according to so 
the present invention is applicable to a video game ap- 
paratus for generating, and supplying to a display, an 
image signal to display a player object existing on a land 
object in a virtual three dimensional space by process- 
ing image data for the player object and the land object 55 
according to a program, and memorized with a program 
to be processed by an information processing means 
included in the video game apparatus, the memory me- 
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dium comprising: a player object image data generating 
program to generate player object image data for dis- 
playing a player object; and a land object image data 
generating program for generating land object image 
data to display a land object; wherein the land object 
image data includes a program control code; and further 
comprising a program control code detecting program 
for detecting the program control code in relation to a 
position of the player object, and an image changing 
program for causing the image signal to change de- 
pending upon the program control code detected. 
[0022] The game program memory medium is formed 
with an image data area. The image data area is mem- 
orized with player object data and land object data. The 
player object data includes polygon data to represent a 
shape and animation data to represent an action state. 
The land object data includes polygon data to represent 
a shape, and attribute data. This attribute data includes 
a program control code including an action code, a cam- 
era code and a sound code. The game memory medium 
further includes a program to process image data. The 
video game apparatus puts forward a game according 
to the image data and programs, while taking into con- 
sideration as required controller data from the controller. 
In response, on a display screen is displayed a game 
image having a player object existing on a land object 
in a virtual three dimensional space. 
[0023] When the player object approaches or exists 
on a relevant land object, a program control code con- 
tained in the land object image data is detected by a 
detecting means. Accordingly, the image changing 
means, which is different from a usual program, controls 
an action of the player object or a virtual camera. 
[0024] Where an action code is contained in the land 
object data representative of a land object at or in the 
vicinity of which the player object is existing, the action 
code is detected by an action code detecting means (ac- 
tion code detecting program). The animation data output 
means (animation data output program) output such an- 
imation data as to cause the player object to make an 
action in accordance with the detected action code. It is 
therefore possible for the player object to automatically 
perform an optimal action in compliance with the detect- 
ed action code. 

[0025] Specifically, when the land object is a hollow 
or hole and the action code is "jump", the animation out- 
put means (animation data output means) outputs ani- 
mation data to cause the player object to make an action 
of jumping across the holbw or hole. 
[0026] When the player object is moving according to 
a direction instructing means on the controller, the mov- 
ing speed detecting means (moving speed detecting 
program) detects a moving speed of the player object 
while the jump distance detecting means (jump distance 
detecting program) calculates a jump distance of the 
player object. In this case, the animation data output 
means (animation data output program) outputs anima- 
tion data to cause the player object to make a jump ac- 
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tion depending upon the jump distance. 
[0027] When the lad object is a wall surface and the 
action code is "climb", the animation data output means 
(animation data output program) outputs animation data 
to cause the player object to climb a wall surface. 5 
[0028] If a wall surface height is calculated by a wall 
surface height calculating means (wall height detecting 
program), it is determined under which range of 0 < H < 
25, 25 < H < 50, 50 < H < 100 or 100 < H < 1 50 the wall 
surface height (H) falls. The animation data output io 
means (animation data output program) outputs anima- 
tion data to cause an optimal action for the wall surface 
height. 

[0029] Furthermore, where the program control code 
is a camera code, for example a plurality of virtual cam- is 
eras properly arranged in the virtual three dimensional 
space is selectively activated by the camera code (cam- 
era switching code). 

[0030] Also, where the program control code is a 
sound code, for example the sound data to be produced 20 
by a sound data generating means is switched over. 
[0031] According to the present invention, required 
control can be automatically made in accordance with 
a control code contained in the land object image data, 
including, say, player object action control, image 2S 
change control including virtual camera switching, and 
sound control such as sound data switching. Even in the 
case that a player object or a camera is controlled com- 
plicately in accordance with a position the player object 
is existing, it is easy to design a program. 30 
[0032] For example, if the program control code is an 
action code, it is very easy for a player to manipulate a 
player object. If the action code is "jump", the player ob- 
ject automatically jumps. Thus, the player object can 
easily get across such an obstacle as a hole or hollow. 35 
If the action code is "climb", the player object can auto- 
matically climbing a wall surface. Where the action code 
is "door", door automatically opens and the player object 
is allowed to enter the door. Further, if the action code 
is "ladder", the player object will automatically goes up 40 
a ladder. 

[0033] The above described objects and other ob- 
jects, features, aspects and advantages of the present 
invention will become more apparent from the following 
detailed description of the present invention when taken «s 
in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 



[0034] 



50 



Figure 1 is a schematic illustrative view showing a 
video game system of one embodiment of this in- 
vention; 

Figure 2 is a block diagram showing in detail a video 55 
game machine of the Figure 1 system; 
Figure 3 is a block diagram showing in detail a con- 
troller control circuit of the Figure 2 video game ma- 



chine; 

Figure 4 is a block diagram showing in detail a con- 
troller and controller pack for the Figure 2 video 
game machine; 

Figure 5 is an illustrative view showing a memory 
map of an external ROM for the Figure 2 video game 
machine; 

Figure 6 is an illustrative view showing a memory 
map of a RAM for the Figure 2 video game machine; 
Figure 7 is a flowchart showing an overall operation 
of the Figure 1 embodiment; 
Figure S is a flowchart showing in detail a land ob- 
ject process in the Figure 7 flowchart; 
Figure 9 is a flowchart showing in detail one part of 
an action determining process in the Figure 7 flow- 
chart; 

Figure 10 is a flowchart showing in detail an action 
determining process for the case of a hole in the 
Figure 9 flowchart; 

Figure 11 is an illustrative view showing one exam- 
ple of a jump (big jump) action to be achieved in the 
Figure 10 flowchart; 

Figure 1 2 is an illustrative view showing one exam- 
ple of a jump (middle jump) action to be achieved 
in the Figure 10 flowchart; 

Figure 1 3 is an illustrative view showing one exam- 
ple of a jump (small jump) action to be achieved in 
the Figure 10 flowchart; 

Figure 1 4 is an illustrative view showing one exam- 
ple of a "not-fair action in the Figure 10 flowchart; 
Figure 15 is a flowchart showing in detail an action 
determining process for the case of a wall surface 
in the Figure 9 flowchart; 

Figure 16 is an illustrative view showing one exam- 
ple of a wall scramble up action to be achieved by 
the Figure 15 flowchart; 

Figure 17 is a flowchart showing one example of a 
step mounting action to be achieved by the Figure 
1 5 flowchart; 

Figure 18 is an illustrative view showing a jump up 
action to be achieved by the Figure 1 5 flowchart; 
Figure 1 9 is an illustrative view showing one exam- 
ple of a light climb action to be achieved by the Fig- 
ure 1 5 flowchart; 

Figure 20 is an illustrative view showing one exam- 
ple of a usual climb action to be achieved by the 
Figure 15 flowchart; 

Figure 21 is an illustrative view showing one exam- 
ple of a hard climb action to be achieved by the Fig- 
ure 1 5 flowchart; 

Figure 22 is a flowchart showing in detail a door ac- 
tion in the Figure 9 flowchart; 

Figure 23 is an illustrative view showing one exam- 
ple of a door action to be achieved by the Figure 22 
flowchart; 

Figure 24 is a flowchart showing in detail a ladder 

action in the Figure 9 flowchart; . 

Figure 25 is an illustrative view showing one exam- 
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pie of a ladder action achieved by the Figure 24 
flowchart; 

Figure 26 is a flowchart showing in detail a player 
object process in the Figure 7 flowchart; 
Figure 27 is an illustrative view showing in detail a 
camera determining process in the Figure 7 flow- 
chart; 

Figure 28 is an illustrative view showing one exam- 
ple of camera arrangement as a premise for the 
camera determining process of Figure 27 flowchart; 
Figure 29 is a flowchart showing in detail a first cam- 
era control program in the Figure 27 flowchart; 
Figure 30 is an illustrative view showing a player 
object taken by a first camera according to the Fig- 
ure 29 flowchart; 

Figure 31 is a flowchart showing in detail a second 
"camera (fifth camera) control program in the Figure 
27 flowchart; 

Figure 32 is a flowchart showing in detail a third 
camera control program of the Figure 27 flowchart; 
Figure 33 is an illustrative view showing a player 
object taken by the third camera according to the 
Figure 32 flowchart; 

Figure 34 is a flowchart showing in detail a fourth 
camera control program in the Figure 27 flowchart; 
Figure 35 is an illustrative view showing a player 
object taken by a fourth camera according to the 
Figure 34 flowchart; 

Figure 36 is an illustrative view showing a player 
object taken by the fourth camera according to the 
Figure 32 flowchart; and 

Figure 37 is a flowchart showing in detail a sound 
process in the Figure 7 flowchart. 

DETAILED DESCRIPTION OF THE PREFFERED 
EMBODIMENTS 

[0035] Referring to Figure 1 , a video game apparatus 
in this embodiment includes a video game machine 10, 
a ROM cartridge 20 as one example of an information 
memory medium, a display unit 30 connected to the vid- 
eo game machine 1 0, and a controller 40. The controller 
40 is dismountably mounted with a controller pack 50. 
[0036] The controller 40 is structured by a plurality of 
switches or buttons provided on the housing 41 in a form 
graspable by both or one hand. Specifically, the control- 
ler 40 includes handles 41 L, 41 C, 41 R downwardly ex- 
tending respectively from a left end, a right end and a 
center of the housing 41 , providing an operation area 
on a top surface of the housing 41 . In the operation area, 
there are provided an analog-inputtable joystick (here- 
inafter referred to as "analog joystick") 45 at a central 
lower portion thereof, a cross-shaped digital direction 
switch (hereinafter called "cross switch") 46 on the left 
side, and a plurality of button switches 47A, 47B, 47D, 
47E and 47F on the right side. 

[0037] The analog joystick 45 is used to input a mov- 
ing direction and/or moving speed or moving amount of 



the player object (object to be operated by a player 
through a controller) as determined by an amount and 
direction of joystick inclination. The cross switch 46 is 
used to designate a moving direction of the player ob- 
5 ject, in place of the joystick 45. The button switches 47A 
and 47B are used to designate a motion of the player 
object. Button switches 47C - 47D are used to switch 
over a visual point of a three-dimension image camera 
or adjust speed or the like of the player object. 
io [0038] A start switch 47S is provided almost at a cent- 
er of the operation area. This start switch 47S is oper- 
ated when starting a game. A switch 47Z is provided at 
a backside of the central handle 41 C. This switch 472 
is utilized, for example, as a trigger switch in a shoot 
15 game. Switches 47L and 47R are provided at upper left 
and right of a lateral surface of the housing 41 . 
[0039] Incidentally, the above-stated button switches 
47C - 47F can also be used to control the motion and/ 
or moving speed (e.g. acceleration or deceleration) of 
20 the player object in a shoot or action game, besides for 
the purpose of switching the camera visual point. How- 
ever, these switches 47A - 47F, 47S, 47Z, 47L and 47R 
can be arbitrarily defined in their function depending up- 
on a game program. 
25 [0040] Figure 2 is a block diagram of the video game 
system of the Figure 1 embodiment. The video game 
machine 10 incorporates therein a central processing 
unit (hereinafter referred to as "CPU") 11 and a coproc- 
essor (reality coprocessor: hereinafter referred to as 
30 "RCP") 12. The RCP 12 includes a bus control circuit 
1 21 for controlling buses, a signal processor (reality sig- 
nal processor; hereinafter referred to as "RSP") 122 for 
performing polygon coordinate transformation, shading 
treatment and so on, and a rendering processor (reality 
35 display processor; hereinafter referred to as "RDP") 46 
for rasterizing polygon data into an image to be dis- 
played and converting the same into a data form (dot 
data) memorable on a frame memory. 
[0041] The RCP 12 is connected with a cartridge con- 
40 nector 13 for unloadably loading a ROM cartridge 20 
having an external ROM 21 incorporated therein, a disc- 
drive connector 197 for detachably mounting a disc 
drive 29, and a RAM 14. Also, the RCP 12 is connected 
with DAC (Digital/ Analog Converters) 15 and 16 for re- 
45 spectivety outputting a sound signal and video signal to 
be processed by the CPU 11. Further, the RCP 12 is 
connected with a controller control circuit 17 to serially 
transfer operating data on one or a plurality of controllers 
40 and/or controller pack 50. 
so [0042] The bus control circuit 121 included in the RCP 
12 performs parallel/serial conversion on a command 
supplied in a parallel signal from the CPU via a bus, to 
thereby supply a serial signal to the controller control 
circuit 18. Also, the bus control circuit 121 converts a 
55 serial signal inputted from the controller control circuit 
17 into a parallel signal, giving an output to the CPU 11 
via the bus. The data representative of an operating 
state (operating signal or operating data) read out of the 
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controller 40A - 40D is processed by the CPU 11, and 
temporarily stored within a RAM 14, and so on. In other 
words, the RAM 1 5 includes a storage site for tempo- 
rarily memorizing the data to be processed by the CPU 
1 1, so that it is utilized for smoothly reading and writing 
data through the bus control circuit 1 21 . 
[0043] The sound DAC 15 is connected with a con- 
nector 19a provided at a rear face of the video game 
machine 1 0. The video DAC 1 6 is connected with a con- 
nector 19b provided at the rear face of the video game 
machine 10. The connector 19a is connected with a 
speaker 31 of a display 30, while the connector 19b is 
connected with a display 30 such as a TV receiver or 
CRT. 

[0044] The controller control circuit 17 is connected 
with a controller connector provided at the front face of 
the video game machine 10. The connector 18 is dis- 
connectably connected by a controller 40 through a con- 
necting jack. The connection of the controller 40 to the 
connector 18 places the controller in electrical connec- 
tion to the video game machine 10, thereby enabling 
transmission/reception or transfer of data therebe- 
tween. 

[0045] The controller control circuit 17 is used to 
transmit and receive data in serial between the RCP 12 
and the connector 18. The controller control circuit 17 
includes, as shown in Figure 3, a data transfer control 
circuit 171, a transmitting circuit 172, a receiving circuit 

173 and a RAM 174 for temporarily memorizing trans- 
mission and reception data. The data transfer control 
circuit 171 includes a parallel/serial converting circuit 
and a serial/parallel converting circuit in order to convert 
a data format during data transfer, and further performs 
write/read control on the RAM 174. The serial/parallel 
converting circuit converts the serial data supplied from 
the RCP 12 into parallel data, supplying it to the RAM 

174 or the transmitting circuit 172. The parallel/serial 
converting circuit converts the parallel data supplied 
from the RAM 1 74 or the receiving circuit 1 73 into serial 
data, to supply it to the RCP 12. The transmitting circuit 
1 72 converts the command for reading signals from the 
controller 40 and the writing data (parallel data) to the 
controller pack 50, into serial data to be delivered to 
channels CH1 - CH4 corresponding to the respective 
controllers 40. The receiving circuit 173 receives, in se- 
rial data, operational state data of the controllers input- 
ted through corresponding channels CH1 - CH4 and da- 
ta read from the controller pack 50, to convert them into 
parallel data to be delivered to the data transfer control 
circuit 171. The data transfer control circuit 171 writes 
into the RAM 1 74 data transferred from the RCP 1 2, da- 
ta of the controller received by the receiving circuit 183, 
or data read out of the RAM controller pack 50, and 
reads data out of the RAM 1 74 based on a command 
from the RCP 1 2 so as to transfer it to the RCP 1 2. 
[0046] The RAM 174, though not shown, includes 
memory sites for the respective channels CH1 - CH4. 
Each of the memory sites is stored with a command for 
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the channel, transmitting data anoVor reception data. 
[0047] Figure 4 is a detailed circuit diagram of the con- 
troller 40 and the controller pack 50. The housing of the 
controller 40 incorporates an operating signal process- 
s ing circuit 44, etc. in order to detect an operating state 
of the joystick 45, switches 46, 47, etc. and transfer the 
detected data to the controller control circuit 1 7. The op- 
erating signal processing circuit 44 includes a receiving 
circuit 441, a control circuit 442, a switch signal detect- 
10 jng circuit 443, a counter circuit 444, a joyport control 
circuit 446, a reset circuit 447 and a NOR gate 448. The 
receiving circuit 441 converts a serial signal, such as a 
control signal transmitted from the controller control cir- 
cuit 17 or writing data to the controller pack 50, into a 
J 5 parallel signal to supply it to the control circuit 442. The 
control circuit 442 generates a reset signal to reset (0), 
through the NOR gate 448. count values of an X-axis 
counter 444X and a Y-axis counter 444Y within the 
counter 444, when the control signal transmitted from 
the controller control circuit 17 is a signal for resetting 
X, Y coordinates of the joystick 45. 
[0048] The joystick 45 includes X-axis and Y-axis pho- 
to-interrupters in order to decompose a lever inclination 
into X-axis and Y-axis components, generating pulses 
in number proportional to the inclination. The pulse sig- 
nals are respectively supplied to the counter 444X and 
the counter 444Y. The counter 444X counts a number 
of pulses generated in response to an inclination 
amount when the joystick 45 is inclined in the X-axis di- 
rection. The counter 444Y counts a number of pulses 
generated responsive to an inclination amount when the 
joystick 45 is inclined in the Y-axis direction. According- 
ly, the resultant X-axis and Y-axis vector determined by 
the count values of the counters 444X and 444Y serves 
to determine a moving direction and a coordinate posi- 
tion of the player object or hero character or a cursor. 
Incidentally, the counter 444X and the 444Y are reset, 
when a reset signal is supplied from the reset signal gen- 
erating circuit 447 upon turning on the power or a reset 
signal is supplied from the switch signal detecting circuit 
443 by simultaneous depression of predetermined two 
switches. 

[0049] The switch signal detecting circuit 443 re- 
sponds to a switch-state output command supplied at 
an interval of a constant period (e.g. a 1/30 second in- 
terval as a TV frame period) from the control circuit 442, 
to read a signal varying depending upon a depression 
state of the cross switch 46 and the switches 47A - 47Z. 
The read signal is delivered to the control circuit 442. 
The control circuit 442 responds to a read-out command 
signal of operational state data from the controller con- 
trol circuit 17 to supply in a predetermined data format 
the operational state data on the switches 47A - 47Z and 
count values of the counters 444X and 444Y to the 
transmitting circuit 445. The transmitting circuit 445 con- 
verts the parallel signal outputted from the control circuit 
442 into a serial signal, and transfer it to the controller 
control circuit 17 via a converting circuit 43 and a signal 
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line 42. The control circuit 442 is connected with a joy- 
stick control circuit 446 via an address bus and a data 
bus as well as a port connector 46. The joyport control 
circuit 446 performs data input/output (or transmission/ 
reception) control according to a command from the 5 
CPU 1 1 when the controller pack 50 is connected to the 
port connector 46. 

[0050] The controller pack 50 is structured by con- 
necting the RAM 51 to the address bus and data bus 
and connecting the RAM 51 with a battery 52. The RAM w 
51 is to store backup data in relation to a game, and 
saves backup data by the application of electric power 
from the battery 52 even if the controller pack 50 is with- 
drawn from the port connector 46. 

[0051] Figure 5 is a memory map illustrating a mem- fS 
ory space of an external ROM 21 incorporated in the 
ROM cartridge 20 (Figure 1, Figure 2). The external 
ROM 21 includes a plurality of memory areas (may be 
hereinafter referred merely to as "areas"), i.e., a' pro- 
gram area 22, an image data area 23 and a sound mem- 20 
ory area 24, which are memorized previously and fixedly 
with various programs. 

[0052] The program area 22 is memorized with a pro- 
gram required to process game images, game data suit- 
ed for a game content, etc. Specifically, the program ar- 2s 
ea 22 includes memory areas 22a - 22i to previously, 
fixedly memorize a CPU 11 operation program. A main 
program area 22a is memorized with a main routine 
processing program for a game shown in Figure 7, etc., 
hereinafter referred to. A controller data determining 30 
program area 22b is memorized with a program to proc- 
ess controller 40 operation data. A land object program 
area 22c is memorized with a program to display and 
control a land object on or in the vicinity of which the 
player object is to exist. A player object program area 35 
22d is memorized with a program to display and control 
an object to be operated by a player (referred merely to 
as "player object"). 

[0053] The program area 22 further includes a control 
code detecting program area 22e. On this area 22e is 40 
installed a program to detect a control code contained 
in land object image data (hereinafter referred to). A 
camera control program area 22f is memorized with a 
camera control program to control in which direction 
and/or position a moving object, including the player ob- *s 
ject, or background object is to be taken in a three di- 
mensional space. In the embodiment a plurality of virtual 
cameras are installed in a three dimensional space. Ac- 
cordingly, the camera control program area 22f includes 
a first camera control program, second camera control so 
program, Nth camera control program to individually 
control respective ones of first to Nth virtual cameras. 
[0054] An action control program area 22g is memo- 
rized with a program to read out animation data con- 
tained in the player object image data, in order to cause ss 
the player object to act according to a control code de- 
tected by a control code detecting program. The action 
control program, concretely, includes various calcula- 
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tion programs. The calculation programs include a mov- 
ing speed detecting program to detect a moving speed 
of the player object, a jump distance calculating program 
to calculate a jump distance of the player object based 
on a moving speed, and a wall height calculating pro- 
gram to calculate a wall height. This action control pro- 
gram determines an action for the player object accord- 
ing to an action code, control code or calculation pro- 
gram, and reads animation data out of the image data 
area 23 depending upon an action. Accordingly, the ac- 
tion control program 22g cooperates with the image data 
area 23 to thereby constitute an animation data output 
program. 

[0055] An image buffer and Z buffer write program ar- 
ea 22h is memorized with a write program by which the 
CPU 1 1 causes the RCP 1 2 to effect writing onto an im- 
age buffer and a Z buffer. For example, the write pro- 
gram area 22h is memorized with a program to write 
color data to the frame memory area (Figure 6) of the 
RAM and a program to write depth data to the Z buffer 
area 204 (Figure 6), as image data based on texture da- 
ta for a plurality of moving objects or background objects 
to be displayed on one background scene. 
[0056] Incidentally, a sound process program area 22i 
is memorized with a program to generate a message 
through effect sound, melody or voices. 
[0057] The image data area 23 includes, as shown in 
Figure 5, two memory areas 23a and 23b. The memory 
area 23a is memorized with image data, such as coor- 
dinate data and animation data of a plurality of polygons, 
on an object-by-object basis, in order to display a player 
object, and with a display control program to display in 
a predetermined fixed position or movably an object. 
The memory area 23b is memorized with image data, 
such as a plurality of ones of polygon data and attribute 
data, on an object-by-object basis to display a land ob- 
ject, and with a display control program to display a land 
object. The attribute data includes an action code rep- 
resentative of an action to be performed by the player 
object (say, jump, wall scramble, door open and close, 
ladder climb, etc), a kind code representative of a kind 
of a land polygon (hole, ice, sand, lava, etc), a melody 
code representative of a kind of BGM, an enemy code 
representative whether an enemy is existing or not and 
an enemy kind, and a camera code to instruct switch 
between cameras. These codes are collectively referred 
to as "control codes". The control codes have been pre- 
viously set wilhin the polygon data of every polygon con- 
stituting the land objects to be set. Incidentally, the land 
objects required are considered to include a land object 
on which the player object is to exist, and a land object 
in the vicinity of which the player object is to exist, and 
so on. 

[0058] A sound memory area 24 is memorized with 
sound data, such as phrases, effect sound and game 
melody, for each scene to output a message as above 
in a manner suited for a relevant scene. Specifically, 
BGM1 and 8GM2 are memorized as a game melody, 
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and sound data such as "outcry" as an effect sound. 
[0059] Incidentally, the memory medium or external 
memory may use an arbitrary memory medium, such as 
a CD-ROM or magnetic disc, in place of or in addition 
to the ROM cartridge 20. In such a case, a disc drive 
(not shown) should be provided in order to read, or write 
as required, various ones of data for a game (including 
program data and image display data) from the optical 
or magnetic disc-formed memory medium, such as a 
CD-ROM or magnetic disc. This disc drive reads out da- 
ta memorized on the magnetic disc or optical disc which 
is magnetically or optically memorized with similar pro- 
gram data to that of the external ROM 21 , and transfers 
the data to the RAM 14. 

[0060] In this manner, the program area 22 is installed 
with the programs so that a game image signal can be 
created by processing the image data set on the image 
data area 23 in a manner similar to the conventional vid- 
eo game apparatus, and a sound signal can be pro- 
duced by processing the sound data installed on the 
sound memory area 24. In this embodiment, further- 
more, a program control code is previously set on the 
image data memorized in the image data area 2^, say, 
in the land object image data. When the program control 
code is detected in dependence upon a position of the 
player object, the animation for the player object is var- 
ied, the virtual camera is switched over and further the 
sound signal is changed in compliance with a detected 
program control code. Thus, the program control code 
serves as a program control factor or program change 
factor. 

[0061] Due to this, if when a program code is detected 
the player object is changed in animation or the camera 
is switched over, it is possible to provide image change 
in a manner different from that by the execution of a usu- 
al program. Also, if when a program control code is de- 
tected the sound signal is switched over, it is possible 
to cause a different sound change from that by execut- 
ing an ordinary program. 

[0062] Incidentally, the control code is explained with 
greater detail. As mentioned above, the land object data 
includes attribute data, wherein the control code is in- 
cluded in the attribute data. The attribute data is a pre- 
determined number of bits of data representative of 
what the present land object is, say, a kind of an object, 
such as a hole, floor, wall surface, stair, grassy land or 
the like. Therefore, the CPU 11 can determine a kind of 
a land object by detecting attribute data. 
[0063] The control code is configured by 1 or 2 or 
more bits in attribute data. The attribute data is included 
within each polygon to constitute a land object. As a re- 
sult, the control data is included in each polygon. The 
control code represents, by 1 or 2 or more bits, a control 
content, say, "jump", 'climb', "enter door", "ladder", 
"camera switch", "sound switch", etc. 
[0064] Incidentally, in the above explanation, a kind of 
a land object was determined by referring to attribute 
data. However, the method for detecting a land object 
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may be as follows. For example, a land object on which 
the player object is moving may be detected as a floor 
object whereby a land object provided at 90 degrees 
(vertically) with respect to the floor object is detected as 
5 a wall or wall surface object. In this case, a land object 
existing at above the player object will be detected as a 
ceiling object. That is, a kind of a land object may be 
determined by a positional relationship, angle or the like 
relative to the player object. 
10 [0065] In either case, a program control code (includ- 
ing a control code, action code, camera code, sound 
code, and so on) is set in attribute data. 
[0066] Figure 6 is a memory map illustrating an entire 
memory space of the RAM 14. The RAM 14 includes 
is various memory areas 201 - 209. For example, the RAM 
1 4 includes a display list area 201 , a program area 202, 
a frame memory (or image buffer memory) area 203 for 
temporarily memorizing 1 frame of image data, a Z buff- 
er area 204 for memorizing, dot by dot, depth data of 
20 the frame memory area data, an image data area 205, 
a sound memory area 206, an area 207 for memorizing 
controller operation state data, a working memory area 
208, and register/flag area 209. The memory areas 201 
- 209 are memory spaces to be accessed through the 
25 bus control circuit 121 by the CPU 11 or directly by the 
RCP 12, and assigned with an arbitrary capacity (or 
memory space) by a game used. Meanwhile, the image 
data area 205 and the sound memory area 206 are to 
temporarily memorize image data or sound data re- 
quired to execute a program transferred to the program 
area 202. which program is a part of data of game pro- 
grams for 1 game entire scene (stage) memorized in the 
memory area 22 of the ROM 21. e.g. a game program 
required for 1 course or stage. In this manner, if the pro- 
gram required for a certain scene or data part are mem- 
orized in the memory areas 202. 205, 206, it is possible 
to enhance data processing efficiency and hence image 
processing speed as compared to the processing by di- 
rectly reading from the ROM 21 each time the CPU re- 
quires. 

[0067] Specifically, the frame memory area 203 has a 
memory capacity corresponding to the number of pic- 
ture elements (pixels or dots) of the display 30 (Figure 
1 ) x the number of bits of color data per pixel, to mem- 
orize color data dot by dot corresponding to the pixels 
on the display 30. The frame memory area 203 tempo- 
rarily memorizes color data dot by dot when displaying 
a moving object, such as a player object, fellow object, 
enemy object, boss object etc. or various other objects 
such as a land object, background (or stationary) object, 
etc. that are memorized in the image data area 105. 
[0068] The Z buffer area 204 has a memory capacity 
corresponding to the number of picture elements (pixels 
or dots) of the display 30 x the number of bits of depth 
data per pixel, to memorize depth data dot by dot cor- 
responding to each pixel on the display 30. The Z buffer 
area 204 temporarily memorizes depth data dot by dot 
when displaying a moving and/or stationary object, i.e. 
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a moving object such as a player object, fellow object, 
enemy object, boss object or the like, and various other 
objects such as a land object, background (or station- 
ary) object or the like that are memorized in the image 
data area 205. 

[0069] The image data area 205 is to memorize coor- 
dinate data and texture data for polygons to be consti- 
tuted in a plurality of sets for each of stationary and/or 
movable objects for game display memorized in the 
ROM 21 , to which 1 course or stage of data, for example, 
is transferred from the ROM 21 in advance of their image 
processing. Incidentally, this image data area 205 also 
memorizes animation data that has been read out, as 
required, from the image data area 23 of the external 
ROM 21. 

[0070] The sound memory area 206 is transferred by 
part of the sound data (data of phrase, melody and effect 
sound) memorized in the memory area of the ROM 21, 
and temporarily memorize it as sound data to be pro- 
duced through a sound producing unit 32. 
[0071] The controller data (operation state data) 
memory area 207 temporarily memorizes operation 
state data representative of an operation state read from 
the controller 40. 

[0072] The working memory area 208 temporarily 
memorizes data such as parameters during execution 
of a program by the CPU 11 . 

[0073] The register/flag area 209 includes register ar- 
ea 209r and flag area 209f. The register area 209r, 
though not shown, is formed with a plurality of registers 
to be individually loaded with data. The register area 
209r, though not shown, is formed with a plurality of flags 
to be separately set or reset. 

[0074] Figure 7 is a main flowchart of the video game 
system in this embodiment. If a power is turned on, in a 
first step S1 , the CPU 11 at a start sets the video game 
machine 10 in a predetermined initial state. For exam- 
ple, the CPU 11 transfers a starting program of the game 
programs memorized on the program area 22 of the ex- 
ternal ROM 21 to the program area 202 of the RAM 14, 
and sets parameters to their initial values, executing se- 
quentially steps of Figure 7. 

[0075] The operation of the main flowchart of Figure 
7 is carried out, for example, at an interval of 1 frame 
(1/60th second) or 2 or 3 frames. The steps S2 - Si 2 
are repeatedly executed until the course has been 
cleared. If the game comes over without successfully 
clearing the course, in step S14 following step S13 a 
game over process is performed. If the course clear is 
successful, the process returns from the step S1 2 to the 
step Si. 

[0076] That is, in the step S 1 is displayed a game 
course screen and/or course selecting screen. Howev- 
er, if the game is started after turning on the power, a 
screen of first course is displayed. If the first course is 
cleared, a next course is set up. 

[0077] In the step S2 following the step S1 is carried 
out a controller process. In this process, detection is 
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made on which one was operated of the joystick 45 of 
the controller 40, cross switch 46 and switches 47A - 
47Z. The operation state detection data (controller data) 
is read in, and the controller data thus read is written 

s onto the controller data area 141 of the RAM 14. 

[0078] In the step S3 a land object process is per- 
formed. This process, though hereinafter explained in 
detail with reference to a subroutine of Figure 8, includes 
a calculation of a land object display position and shape 

io based on a program partly transferred from the memory 
area 22c and land object polygon data transferred from 
the memory area (Figure 5). 

[0079] In the step S4 a process is executed to deter- 
mine an action for the player object. Concretely, as ex- 
15 plained hereinafter with reference to Figure 9 to Figure 
26, determination is made on an action for the player 
object according to a control code or action code ex- 
plained before. 

[0080] In step S5 a process is performed to display a 
20 player object. This process is basically a process to 
cause changes in position, direction, shape and location 
on the basis of a joystick 45 operating state (controller 
data) operated by a player and the presence or absence 
of enemy attack. For example, the polygon data after 
2S change is determined by calculation based on the pro- 
gram transferred from the memory area 22e (Figure 5) 
of the external ROM 21 , the player object polygon data 
transferred from the memory area 23a, and the control- 
ler data, i.e. joystick 45 operating state Colors are given 
30 by texture data to a plurality of polygons obtained by the 
above. 

[0081] The step S6 is a step to carry out a camera 
determination process. In concrete, it is determined 
which virtual camera of a plurality of virtual cameras is 

35 to be used in taking pictures of an object in a virtual three 
dimensional space, according to a switch code (control 
code) contained in land object data explained before. 
This will be hereinafter explained in detail with reference 
to Figure 27 to Figure 36. 

40 [0082] In the step S7 a camera process is carried out. 
For example, a coordinate of a visual point to the object 
is calculated such that a line or field of sight as viewed 
through a viewfinder of the virtual camera comes to an 
angle designated through the joystick 45 by the player. 

45 [0083] In the step S8 the RSP 1 22 performs a render- 
ing process. That is, the RCP 12 under the control of 
CPU 11 performs transformation (coordinate transfor- 
mation and frame memory rendering) on the image data 
to display a movable object and stationary object based 

so on the texture data for the movable object, such as an 
enemy object, player object, or the like, and the station- 
any object, such as for background, memorized in the 
image data area 201 of the RAM 1 4. Specifically, colors 
are given to a plurality of polygons for each of a plurality 

55 of movable objects and stationary objects. 

[0084] In the step S9, the CPU 11 performs a sound 
process based on sound data, such as messages, mel- 
ody, effect sound, etc. In particular, BGM and the like 
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are switched over according to a melody code (control 
code) previously set in the land object, as shown in a 
subroutine of Figure 37. 

[0085] In the next step S10 the CPU 11 reads out im- 
age data memorized on the frame memory area 203 of 
the RAM 14, according to a result of the rendering proc- 
ess of the step S7. Accordingly, a player object, moving 
object, stationary object and enemy object, and the like 
are displayed on a display screen of the display 30 (Fig- 
ure 1, Figure 2). 

[0086] In the step S11, the RCP 12 reads out the 
sound data obtained as a result of the sound processing 
of the step Si 8, thereby outputting sound such as mel- 
ody, effect sound, conversation, etc. 
[0087] In the step S12 whether the course was 
cleared or not is determined (course clear detection). If 
the course was not cleared, it is determined in the step 
S1 3 whether the game is over or not. If not game over, 
process returns to the step S2 to repeat the steps S2 - 
S 1 3 until a condition of game over is detected. I f a game 
over condition is detected, i.e. the number of mistakes 
permitted for the player reaches a predetermined 
number of times or the life of player object is consumed 
by a predetermined amount, then in the step S14 is ef- 
fected a game over process, such as a selection of 
game play continuation or backup data memorization. 
[0088] Incidentally, in the step S12 if a condition of 
clearing the course (e.g. defeating a boss, etc.) is de- 
tected, the course clear process is carried out and there- 
after the process returns to the step S1 . 
[0089] Figure 8 is a subroutine of the land object proc- 
ess shown in the step 53 of Figure 7. In a first step 301 , 
the CPU 1 1 (Figure 2) reads out polygon data, or a land 
object required at that time, transferred from the image 
data area 23 (Figure 5) of the external ROM 21 to the 
image data area 205 (Figure 6) of the internal RAM 14. 
This polygon data has a control code previously set as 
required therein, as was explained before. Accordingly, 
if the step S301 is executed, the same control data is 
simultaneously read out. Incidentally, the read polygon 
data containing a control code (action code, camera 
switch code, sound code or the like) is temporarily held 
in a display list area 201 of the internal RAM 14. 
[0090] In step S302 texture data is read out which cor- 
responds to the land object and transferred to the image 
data area 205 of the internal RAM 1 4. In step S303 cam- 
era data is similarly read out of the image data area 205 
which corresponds to that land object. These texture da- 
ta and camera data are memorized on the display list 
area 201 , similarly to the polygon data. 
[0091] Then, in step S304 the land object is memo- 
rized in the display list area 201 . It is determined in step 
S305 whether the process of from the step S301 to the 
step S304 has been executed on all the land objects or 
not. If the determination is "NO", the process is again 
executed from the step S301 . If all the land objects has 
been completed of the process, i.e. if "YES" is deter- 
mined, the subroutine of Figure 8 is ended and the proc- 



ess returns to the main routine. 

[0092] The action determination process in Ihe step 
S4 of Figure 7 is carried out, concretely, according to a 
flowchart shown in Figure 9. That is : in the first step 
5 S401 the CPU 1 1 (Figure 2) detects a state of the player 
object. That is, whether the player object is in any action 
or not is detected. If the player object is in a course of 
an action, "YES" is determined in step S402, and the 
process advances to the succeeding step S403. 
io [0093] In the step S403 the CPU 1 1 makes reference 
to the register/flag area 209 of the RAM 14 shown in 
Figure 6, and detects a control code or action code con- 
tained in the object data of a land object existing at the 
foot of the player object. The control code or action code, 
*5 as was explained before, has been previously set within 
the land object area 23b of the external ROM 21 shown 
in Figure 5, and previously transferred to the image data 
area 205. The land object data is read onto the display 
list area 201 every frame. Consequently, the CPU 11 
detects an action code in the display list area 201. 
[0094] Subsequently, the CPU 11 in step S404 de- 
tects whether the player object is in falling or not. That 
is, the player object is determined in action in the pre- 
ceding step S402, and it is determined that the action is 
lair action or not. 

[0095] If the player object is in falling, then the CPU 
11 in the next step S405 detects a height of the player 
object at that time from the land object. The CPU 11 in 
step S406 determines that the player object should 
make a landing when the height of the player object from 
the land object is at a predetermined height, i.e. the 
height is sufficiently low. At this time, the CPU 11 in the 
next step S407 causes the player object to begin a land- 
ing action. 

[0096] That is, the CPU 11 in this step S407 causes 
the player object to change in form based on landing- 
action animation data memorized in the player object 
data area 23a of the external ROM 201 , and control the 
RCP 12 to write color data to the frame memory area 
203. Incidentally, this animation data is data represent- 
ative of movement in skeleton of player object. The play- 
er object is to be displayed by a combination of the an- 
imation data and the polygon data, similarly to the ob- 
jects. Accordingly, even with same polygon data if ani- 
mation data is different, the player object changes in ac- 
tion. Due to this, in this step S407 by reading out ani- 
mation data for "landing action" the player object can be 
caused to make a landing action. 

[0097] If it is determined in the previous step S402 that 
the player object action state is not "in the course of an 
action", the CPU 11 in step S408 detects a control code 
or action code for a land object existing nearby (in front 
or at the foot of) the player object from the display list 
area 201, similarly to the step S403. In the next step 
S409, the CPU 11 makes reference to the attribute data 
of the land object at the foot of the player object, thereby 
determining whether the land object is a "hollow" or 
"hole". Alternatively, the land object at that time is a hol- 
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low or hole may be determined from that there is a floor 
object located at zero degree (parallel or horizontal) with 
respect to a moving direction of the player object and 
the floor object is formed with a downward step. 
[0098] Where the land object is a "hollow - or "hole", 
the CPU in the succeeding step S410 executes a "hole 
action 0 subroutine shown in Figure 10. If "NO" is deter- 
mined in the step S409, then it is determined in step 
S411 whether the land object is "wall surface or not by 
the attribute code. However, as stated before, a wall sur- 
face object may be detected by an angle (90 degrees) 
with respect to the player object advancing direction or 
the floor object. If the land object is a "wall surface", the 
CPU 11 in the succeeding step S412 executes a "wall 
surface action " subroutine shown in Figure 16. If "NO" 
is determined in the step S411 , then it is determined in 
step S41 3 whether the land object is a "door" by the at- 
tribute code or an angle to the floor object. Where the 
land object is a "door", CPU in the succeeding step S41 4 
executes a "door action" subroutine shown in Figure 23. 
If "NO" is determined in the step S413, then it is deter- 
mined in step S41 5 whether the land object is a "ladder" 
or not by the attribute code or by an angle to the floor 
object. Where the land object is a "ladder" the CPU 11 
in the succeeding step S416 executes a "ladder action" 
subroutine shown in Figure 25. 

[0099] Explanation is herein made on a "hole action" 
with reference to Figure 1 0 as well as Figure 1 1 to Figure 
15 related thereto. In the first step S417 of Figure 10, 
reference is made to the display list area 201 (Figure 6) 
to detect an action code or control code for the land ob- 
ject at the foot of the player object in front of the hole. 
More specifically, if the attribute data of a floor object 
constituting a "hole" includes 1 or 2 bits or more of a 
control code and the control code is "0", the control code 
is set as default to "jump". Meanwhile, the control codes 
of a floor object constituting a hole includes, besides 
this, "bottomless pit", "scene switching", "not-fall", "step 
off" and so on. 

[0100] If the control code or action code detected in 
step S41 8 is not a "not-fall" code, i.e. , where the control 
code or action code is "jump", "NO" is determined in the 
step S418. The CPU 11 in the next step S419 deter- 
mines a height of the player object at that time from a 
land object, in a similar manner to the previous step 
S405. 

[0101] It is determined in step S420 whether the cal- 
culated height of the player object is lower than a pre- 
determined height, e.g. "200 cm", or not. It is noted that 
"cm" is by a virtual length unit within a virtual three di- 
mensional space, as applied to the hereunder. If "NO" 
is determined in this step S420, the CPU 11 in the next 
step S421 calculates a moving speed of the player ob- 
ject at that time. In step S422 the CPU 11 calculates a 
distance over which the player object is to jump based 
on the height calculated in the step S41 9 and the speed 
calculated in the speed S421 . In the next step S423 the 
action of a jump is started according to the jump dis- 



tance. 

[0102] Figure 11 shows one example of such a jump 
action that the player object can jump across a hole to 
an opposite bank because of a short distance L1 of the 
5 hole. Figure 1 2 shows one example of such a jump ac- 
tion that because the hole is somewhat long in distance 
L2 the player object cannot jump across the hole but can 
lay his hand on the opposite bank. Figure 1 3 shows one 
example of such a jump that the hole distance L3 is too 

10 long for the player object to jump across the hole or to 
lay his hand on the opposite bank resulting in fall into 
the hole. In any of the cases, a jump action required is 
automatically effected according to a jump code con- 
tained in a land object existing thereon. 

'5 [0103] The distance that the player object can jump 
across is correlated to a moving speed of the player ob- 
ject. That is, if the player object is running fast, it can 
jump across a large hole alike the distance L. However, 
when the player object is moving by walk : there may be 

20 a case that the player object cannot jump across the 
hole even if the control code "jump" has been set. Con- 
sequently, when the player object is walking, the player 
object may not jump across but fall into the hole or may 
. be going to fall into a hung position with only the hand 

zs laid on the opposite cliff. 

[0104] Such jump actions can be achieved by reading 
corresponding animation data from the player object da- 
ta area 23a of the external ROM 221 , as was explained 
before. 

30 [0105] Incidentally, if "YES" is determined in the step 
S418, i.e. if the control code or action code of a land 
object in front of the hole is a "not-fall" code, the CPU 
11 in step S424 causes the player object to begin an 
action of not-fall. In this case, the player object is, going 

35 to fall into the hole but assumes a position of being hung 
down with only the hand laid on the opposite cliff. 
[0106] Meanwhile, if in step S420 the height of the 
player object is determined less than 200 cm, it is de- 
termined that no jump should be effected. In step S425 

40 the CPU 11 starts the player object to make an action 
to fall. That is, if the height or depth of the hole is greater 
than 200 cm (virtual length), a jump action as mentioned 
above is executed. If less than 200 cm, the player object 
is caused to move walking into the hole as it is without 

45 jump as shown in Figure 1 4. 

[0107] If "NO" is determined in the step S409, in step 
S411 attribute data or an angle is referred to, thereby 
determining a kind of a land object is a "wall surface" or 
not. If "YES" is determined in this step S411, the CPU 

50 11 in step S412 starts an action "wall surface action" 
which is to be made when the player object is faced with 
a wall surface. This wall surface action is executed, con- 
cretely, according to a flowchart shown in Figure 15. 
[0108] In the first step S426 of Figure 15, the CPU 11 

55 determines whether or not a control code or action code 
contained in a land object "wall surface" existing nearby 
the player object is "forbid" that is to forbid the player 
object from getting over a wall surface. If a "forbid" code, 
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the process returns to the main routine. 
[01 09] When a control code or action code contained 
in each polygon constituting the wall surface is "climb", 
the CPU 11 in step S428 causes the player object to 
perform a wall-surface climbing action, as shown in Fig- 
ure 16. In the Figure 16 example, the player object if 
brought into contact with a wall is put onto the* wall sur- 
face whereby it is moved over the wall surface in re- 
sponse to player's joystick 45 operation. Turning upward 
the joystick 45 causes the player object to climb up the 
wall surface, while turning it downward cause the player 
object to move down. If the player object moves up to a 
wall surface position where the control code ■climb'' is 
not set, the player object can no longer lie on the wall 
surface resulting in fall down. That is, if the wall surface 
object faced with the player object is set with an action 
coda "climb", the player object automatically makes an 
action of climbing up the wall surface. Nevertheless, the 
moving direction of the player object can be determined 
through the joystick 45. 

[0110] Where the control code or action code of the 
wall surface object is not "forbid" and not "climb" and 
further a floor object in front of a wall surface object is 
set as default with control code "jump 1 , the CPU 11 in 
step S429 calculates a wall surface height. Thus the 
player object automatically performs its optimal action 
in accordance with the calculated wall surface height, 
as hereinafter described. 

[0111] At first, the CPU 11 determines in step S430 
whether or not the calculated wall surface height lies 
within a range of from 0 to 25 cm, i.e.. 0 < H ^25 or not. 
The height in this range means very low wall surface. In 
this case, the player object can get over the wall surface 
as if it went up stairs. Consequently, in the next step 
S431 the CPU 11 reads required animation data out of 
the external ROM 21 , or RAM 14, for the player object 
to begin an action "going up stairs" shown in Figure 17. 
In the Figure 17 example, the wall surface to get over is 
small in height. Accordingly, the player object can get 
over the stairs as a wall surface by an action of treading 
the stairs step by step according to the control code 
"jump" set in the floor object. In this case, the control 
code "jump" has previously been set in the floor object 
in front of the wall surface object, or stairs, as shown in 
Figure 17. 

[01 1 2] The CPU n , in the succeeding step S432, de- 
termines whether or not the wall surface height is in a 
range ol from 25 cm to 50 cm, i.e. 25 < H ^ 50 or nol. 
This range of height means a low wall surface. In this 
case : the player object can get over the wall surface by 
jumping. Accordingly, the CPU 1 1 in the next step S433 
reads required animation data out of the ROM 21, or 
RAM 1 4, to cause the player object to begin an action 
"jump" shown in Figure 18. In Figure 18 example, the 
player object jumps at the front of the wall surface to 
land thereon, thus getting over the wait surface. In also 
this case, a control code "jump" has previously been set 
in a land object, or floor object, in front of the wall surface 
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object, as shown in Figure 18. 

[011 3] In step S434. the CPU 1 1 determines whether 
or not the wall surface height is in a range of from 50 cm 
to 1 00 cm, i.e.. 50 < H ^ 1 00 or not. This range of height 

5 means a comparatively high wall surface. In this case, 
the player object can get over the wall surface by light 
climbing. Accordingly, in the next step S435 the CPU 11 
reads out required animation data to cause the player 
object to begin an action "light climb" shown in Figure 

io 19. in the Figure 19 example of "light climb" : the player 
object puts his hands on the wall surface as an object 
so that the body is pushed up atop the wall surface 
through a hand's chinning force and a foot's jump force. 
In this case, a control code "jump" has previously been 

is set in a floor on this side of the wail surface, as shown 
in Figure 19. 

[0114] In step S436, the CPU 11 determines whether 
or not the wall surface height is in a range of from 100 
cm to 150 cm, i.e. 100 < H ^ 150 or not. This range of 

20 height means a high wall surface. In this case, the player 
object can get over the wall surface by usual climbing. 
Accordingly, the CPU 11 in the next step S437 reads out 
required animation data to cause the player object to 
begin an action "middle climb" shown in Figure 20. In 

25 the Figure 20 example of "middle climb", the player ob- 
ject responds to a "jump" code contained in a floor object 
in front of the floor, and lightly jumps at the front of the 
objective wall surface put his hand on a wall surface top 
end. The player object at that time is in floating at feet 

30 so that the body is lifted to the wall top end only through 
a hand's chinning force. 

[0115] In step S438, the CPU determines whether or 
not the wall surface height is in a range of from 150 cm 
to 250 cm, i.e. 1 50 < H ^ 250 or not. This range of height 

35 means a extremely high wall surface. In this case, the 
player object can get over the wall surface by hard climb- 
ing. Accordingly, the CPU 1 1 in the next step S439 caus- 
es the player object to begin an action "hard climb" 
shown in Figure 21. In the Figure 21 example of "hard 

40 climb", the player object responds to a control code 
"jump" in a floor object in front of the objective wall sur- 
face, and makes a high jump to put its hand on a wall 
top end. The player object at feet is in floating so that 
the body is lifted to a top wall end through only a hand's 

45 chinning force. 

[0116] In this manner, the CPU 11 detects a control 
code or action code contained in the object data of a 
land object at or in the vicinity of which the player object 
is existing, whereby the player object is caused to make 

50 an action in accord with the control code or action code, 
i.e. wall getting over in the embodiment. It should be not- 
ed that, where the control code or action code contained 
in the wall surface object is "climb", getting over the wall 
surface is by "climbing" instead of "jumping" as was ex- 

55 plained before. Meanwhile, if a "forbid" code is embed- 
ded in the wall surface object, the player object is not 
allowed to get over the wall surface. 
[0117] Figure 22 shows a subroutine for "door action 
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"shown in step S414 of Figure 9. In the first step S440 
of Figure 22, the CPU 11 makes reference to the con- 
troller data area 207 of the RAM 14 and determines 
whether the A button 47A (Figure 1) is being operated 
by the player or not. If the A button 47A is not being 
operated, the player is determined not having an inten- 
tion to cause the player object enter the door, the proc- 
ess being returned as it is to the main routine. 
[0118] If "YES- is determined in the step S440, the 
CPU 11 in the next step S441 makes reference to the 
image data area 205 (Figure 6) and detects a door po- 
sition from a coordinate position of a polygon constitut- 
ing the door In the next step S442, the player object is 
corrected in position so that the player object is correctly 
positioned in a position to open the door, based on the 
door position as detected in the step S441 . The correct- 
ed player object position is recorded in the image data 
area 205. Thereafter, in step S443 a door action is car- 
ried out. That is, the CPU 1 1 reads required polygon da- 
ta or animation data from the image data area 205, to 
make the player object perform a series of door actions 
(i.e. to grip a knob, open the door, enter the door, and 
close the door). Figure 23 illustrates a state that in this 
door action the player object is going to enter a door. 
That is, in the "door action" to be executed in the step 
S413 of Figure 9, the player object is automatically 
caused to make a door opening and closing action ac- 
cording to a "door code" previously set in a land object 
shown in Figure 23. 

[0119] Incidentally, in the above embodiment expla- 
nation was made that the "door" is set as a control code 
or action code in a floor object immediately in front of 
the door. Contrary to this, the "door" code may be set 
on the door object . 

[0120] Figure 24 shows a detail of an action "ladder* 
to be executed in step S416 of Figure 9. In the first step 
S444 of Figure 24, the image data area 205 (Figure 6) 
is referred to detect a ladder position from a coordinate 
position of a polygon constituting the ladder. In the next 
step S445, the player object is corrected in position such 
that player object is positioned at the foot of the ladder, 
based on a ladder position detected by the step S444. 
The corrected player object position is recorded in the 
image data area 205. Thereafter, in the step S446 a lad- 
der action is carried out. That is, the CPU 11 reads re- 
quired polygon data or animation data from the image 
data 205, and causes the player object to perform a se- 
ries of a ladder-climbing action, i.e. to put hands and 
feet on the ladder and alternately move left and right 
hands and feet on the ladder. Figure 25 illustrates a state 
that the player object goes up the ladder to a midway 
thereof. That is, for the "ladder action" to be executed 
in step S416 of Figure 9, the player object is automati- 
cally caused to perform a ladder climbing according to 
a "ladder* code previously set in a land object shown in 
Figure 25, i.e. wall surface object. 
[0121] Explaining in greater detail, in the Figure 25 
embodiment no control code "step off' has been set in 
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the floor object in front of the wall surface object consti- 
tuting the ladder. Accordingly, the player object can 
make a "ladder climb" action according to a control code 
"ladder" for the wall surface object. That is, there is no 
s affection on the ladder climb action unless the control 
code in the floor object is on "step off*. If a "ladder" code 
is set on the wall surface, the player object when facing 
the wall surface with the ladder automatically grips the 
ladder. Thereafter, the player object goes up the ladder 
10 if the player tilts the joystick 45 (Figure 1 ) up, and comes 
down if it is tilted down. If the player object reaches an 
uppermost position of the ladder, the player object au- 
tomatically steps on a floor close thereto. Meanwhile, if 
the player object comes from the upper floor to the lad- 
's der an "enter ladder" code set in a wall surface object 
on the back of the ladder is detected so that the player 
object can go down the ladder according to the code. 
[01221 In this manner, according to this embodiment, 
it is possible to cause the player object to automatically 
20 make a different action depending upon a control code 
or action code previously contained in a land object 
where the player object exists. Accordingly, program 
setting is very easy to control the action of the player 
object. 

25 [0123]' Incidentally, a flowchart shown in Figure 26 
represents a player object processing operation for the 
step S5 of the main routine of Figure 7. In the first step 
S501 , the CPU 1 1 determines whether the player object 
is in a course of action or not. If in a course of action, a 

30 position and pose of the player object are determined 
so that the player object continues its action. The pose 
is determined by animation data as was explained be- 
fore. 

[0124] If the player object is not in a course of action, 

35 the CPU 11 in the following step S503 detects an oper- 
ation state of the joystick 45 (Figure 1 , Figure 4) included 
in the controller 40. Subsequently, a moving direction, 
moving speed and position and pose of the player object 
are determined respectively in steps S503, S504 and 

^0 . S505, according to an operation state of the joystick 45. 
In step S507, the player object is registered to the dis- 
play list area 201 (Figure 6) of the RAM 14, similarly to 
the case after passing through the step S502. In re- 
sponse, the player object is to be displayed depending 

45 upon the joystick 45 operation state. 

[01 25] The camera determination process in the step 
S6 of the Figure 9 main routine is explained in detail with 
reference to Figure 27 as well as the related figures. In 
the first step S601 of Figure 27, the CPU 11 makes ref- 

50 erence to the data in the image data area 205, and de- 
tects a control code (camera code) previously set in the 
object data of a land object existing underneath the play- 
er object. In each of steps S602, S604, S606, S608 and 
S61 0, it is determined whether the detected control code 

55 is a first camera code, second camera code, third cam- 
era code, fourth camera code or fifth camera code. 
[0126] Explanation is made herein on a first camera, 
second camera, third camera, fourth camera, and fifth 
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camera which have been placed in the virtual three di- 
mensional space in the embodiment, based on Figure 
28. In an example of Figure 28. a longitudinal wall is 
provided in almost a center of a space that is rectangular 
in plan, wherein a door is formed on one part of the wall. 
A third camera is fixedly set up on one side of the door 
(on side of door opening) which is directed to the door. 
On an opposite side to the door, a fourth camera is set 
up. This fourth camera is provided as a zoom camera 
to take a player object that is going to open and enter 
the door. Furthermore, a second camera and fifth cam- 
era are individually, fixedly set up at two respective cor- 
ners in the space. The first camera is provided as a mov- 
able camera which is allowed to move following the play- 
er object. Camera control is explained below on an as- 
sumption of this embodiment having the five virtual cam- 
eras in the three dimensional space as above. However, 
it is needless to say that the number, arrangement and 
function or roll (fixing, moving, zooming, etc.) can be ap- 
propriately modified as required. 

[01 27] Note that in Figure 28 the terms "first camera", 
"second camera .... "fifth camera* given in blocks (rec- 
tangular lattices) respectively represent control codes, 
or camera codes, previously having been set in the land 
objects of this three dimensional space. Consequently, 
when the player object is existing in one block, the player 
object will be taken by a camera corresponding to a 
camera code having been set on that block. 
[0128] Referring back to Figure 27, if a first camera 
code is detected in step S602 : then in the following step 
S603 a first camera control program is selectively set. 
The camera control program, as explained before, is set 
in the camera control program area 22f (Figure 5) of the 
external ROM 21 , which is transferred as required to the 
program area 202 of the internal RAM 14. Accordingly, 
the CPU 11 in step S603 reads a first camera control 
program out of the program area 202 (Figure 6). 
[0129] The first camera control program is a control 
program for the first camera, and the first camera is ar- 
ranged to move following the player object as described 
before. In the first camera control program detailed in 
Figure 29. in step S61 2 the data in the image data area 
205 (Figure 6) is first referred to detect a position of the 
player object. In the next step S613, the CPU 11 deter- 
mines a position of the first camera such that the dis- 
tance from the player object to the first camera becomes 
constant. In step S61 4 the first camera is directed of pic- 
ture taking direction to the player object. Accordingly, 
the first camera is to take a player object-back view with 
a constant distance. 

[0130] In a second camera control program to be ex- 
ecuted in step S605 (Figure 27), in the first step S615 a 
position of the player object is detected as shown in Fig- 
ure 31, similarly to the former step S612 (Figure 29). 
Then, in step S616, the second camera is directed of 
picture taking direction to the player object. That is, the 
second camera is to take the player object from a fixed 
position shown in Figure 28. 



[01 31] Incidentally, because the fifth camera is a fixed 
camera likewise the second camera, a fifth camera con- 
trol program to be selected in step S611 is similar to the 
second camera control program of Figure 31 . 
5 [01 32] The third camera is fixedly set up in front of the 
door as was shown in Figure 28. Accordingly, the third 
camera is to merely take the player object entering or 
exiting the door from a constant distance point. Due to 
this, the third camera control program of step S607 (Fig- 

10 ure 27) includes the step S61 7 of Figure 32. In this step 
S61 7 the third camera is directed of picture taking direc- 
tion to the door. Accordingly, the manner the player ob- 
ject is entering or exiting the door will be taken by the 
third camera, as shown in Figure 33. 

is [0133] Figure 34 shows a detail of a fourth camera 
control program to be executed in step S609 of Figure 
27. The fourth camera is chosen, as will be well under- 
stood from Figure 23, when detected is a fourth camera 
code having been set on a block to which the player ob- 

20 ject has entered. In the first step S618of Figure 34, the 
number of frames is detected after detecting a fourth 
camera code and step S609 is entered, i.e. after camera 
change over. This is because there are two ways in 
which the fourth camera takes the player object. If the 

2S numbec of the frames is less than a predetermined 
number , i.e. when immediately after camera change 
over, "YES" is determined in step S61 9. In this case, the 
CPU 11 in step S620 controls the fourth camera such 
that the fourth camera takes, from a predetermined po- 

30 sition, the player object entering the door. The player 
object taken by the fourth camera in the step S620 is 
illustrated in Figure 35. As will be understood from Fig- 
ure 35, the fourth camera fixedly provided at the position 
shown in Figure 28, in the step S620 wherein at imme- 

35 diately after camera change over, takes as a distant view 
the player object entering the door. That is, the fourth 
camera takes a comparatively wide range including the 
player object. Consequently, where the player object is 
entering the door as in this embodiment, from overall- 

40 view display the player can readily understand where 
the player object as a hero is now existing. 
[0134] Before elapsing a predetermined number of 
frames or time from the camera change over but not im- 
mediately after that camera change over, "NO" is deter- 

45 mined in step S621. In this case, in the following step 
S622 the CPU 11 causes the fourth camera to zoom up 
in order to take as a close-range view the player object, 
as shown in Figure 36. That is, the picture taking is in a 
comparatively narrow range but including the player ob- 

s° ject. 

[0135] If a predetermined number of frames has 
elapsed, "YES" is determined in the step S621. In this 
case, the CPU 11 switches from the fourth camera over 
to the first camera, as shown in step S623. 
55 [0136] In this manner, according to this embodiment, 
it is possible to automatically switch over the camera to 
take the player object and its function depending upon 
a control code, or camera code, previously contained in 
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a land object where the player object is existing. Con- 
sequently, even where troublesome camera switching 
is necessary, it is very easy for a program to set up there- 
for. Meanwhile, where the camera is switched depend- 
ing upon a position of the player object (X-Y coordinate 
position), camera switching if same in X-Y coordinate is 
effected similar irrespective of a 2 coordinate, or height. 
On the contrary, in the method of this embodiment the 
camera switching codes are embedded in the land ob- 
jects. Accordingly, in the case of in a same X-Y plane 
but different in height (Z), it is possible to set a different 
land object, i.e. camera code, and hence a differenct 
camera. That is, in the embodiment, camera switching 
is feasible in a three dimensional fashion. 
[0137] Incidentally, after ending any of the steps 
S620, S622 and S623, the process returns to the main 
routine. 

[01 38] Referring to Figure 37, the explanation is made 
in detail on the step S9 of the Figure 7 main routine, i. 
e. sound processing. This sound processing utilizes the 
control codes explained before. Consequently, in the 
first step S624 of Figure 37, reference is made to the 
image data area 205 to detect a control code, or melody 
code, set on a land object where the player object is ex- 
isting thereon. In step S625, it is determined whether 
the control code, or melody code, is on BGM1 or not. 
The melody code BGM1 is a code to select a first BGM 
(Back-Ground ). Consequently, after "YES" is deter- 
mined in step S625, the CPU 11 in step S626 reads mel- 
ody or sound data for the first BGM out of the sound 
memory area 206 shown in Figure 6, and output it to the 
bus control circuit 121 (Figure 2). 
[0139] If "NO" is determined in step S625, it is deter- 
mined in step S627 whether or not the control code, or 
melody code, is for BGM2. The melody code BGM2 is 
a code to select a second BGM. Accordingly, after "YES" 
is determined in step S627, the CPU 11 in step S628 
reads melody or sound data for the second BGM out of 
the sound memory area 206, and outputs to the bus con- 
trol circuit 121. 

[0140] After "NO" is determined in both steps S625 
and S627, the CPU 11 in step S629 determines whether 
the control code, or melody code, is for "outcry" or not. 
The melody code "outcry" is a code to generate a effect 
sound of outcry. Consequently, after "YES" is deter- 
mined in the step S629, the CPU 11 in step S630 reads 
sound data for "outcry" out of the sound memory area 
206, and outputs it lo the bus control circuit 21. 
[0141] Incidentally, when the control code or melody 
code or sound code is different from the ones described 
above, then in step S631 another one of sound data is 
set up. 

[0142] In this manner, according to this embodiment, 
it is possible to automatically switch the sound to gen- 
erate it in accordance with a control code, or sound 
code, contained in a land object where the player object 
exists. Accordingly, even where troublesome control is 
necessary for switching sound, it is easy for a program 



to set up therefor. 

[0143] Although the present invention has been de- 
scribed and illustrated in detail, it is clearly understood 
that the same is by way of illustration and example only 
s and is not to be taken by way of limitation, the spirit and 
scope of the present invention being limited only by the 
terms of the appended claims. 



10 Claims 



A video game apparatus for generating, and sup- 
plying to a display, an image signal for displaying a 
player object existing on a land object in a virtual 
three dimensional space by processing image data 
for the player object and the land object according 
to a program, said video game apparatus compris- 
ing: 

a player object image data generating means 
for generating player object image data to dis- 
play a player object; and 
a land object image data generating means for 
generating land object image data to display a 
land object; wherein 

said land object image data includes a program 
control code; 

said video game apparatus further comprising 
a program control code detecting means to de- 
tect said program control code in relation to a 
position of the player object, and an image 
changing means to cause the image signal to 
change depending upon the program control 
code detected. 
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2. A video game apparatus according to claim 1 , 
wherein said program control code includes an ac- 
tion code to control an action of said player object, 
said image changing means including animation 

40 data output means to output animation data to au- 
tomatically cause said player object to make an ac- 
tion in accordance with the action code. 

3. A video game apparatus according to claim 2, 
45 wherein when the land object is a hollow or hole and 

the action code is "jump*, said animation data out- 
put means outputttng animation data to cause the 
player object to make an action of jumping over said 
hollow or hole. 

so 

4. A video game apparatus according to claim 3, 
wherein said video game apparatus has a control- 
ler, in association therewith, including a direction in- 
structing means to instruct a moving direction of 

S5 said player object so that the player object is moved 

in the moving direction, said video game apparatus 
further comprising; 
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a moving speed detecting means for detecting 
a moving speed of the player object, and 
a jump distance calculating means for calculat- 
ing a jump distance of the player object based 
on the moving speed, 

said animation data output means outputting 
animation data to cause the player object to 
make an action of jump according to the jump 
distance. 

5. A video game apparatus according to claim 2, 
wherein when the land object is a wall surface and 
the action code is "climb - , said animation data out- 
put means outputs such animation data that the 
player object makes an action of climbing said wall 
surface. 

6. A video game apparatus according to claim 5, 
wherein when the action code is not "climb", a wall 
surface height calculating means is further com- 
prised to calculate a height of said wall surface, 

said animation data output means outputting 
such animation data that the player object makes 
an optimal action in accordance with the height of 
said wall surface. 
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11. A video game apparatus for generating, and sup- 
plying to a display, an image signal to display a play- 
er object existing on a land object in a virtual three 
dimensional space by processing image data for 
the player object and land object according to a pro- 
gram, and further supplying a sound signal to a 
sound output means by processing sound data ac- 
cording to a program, said video game apparatus 
comprising: 

a player object image data generating means 
for generating player object image data to dis- 
play a player object; and 
a land object image data generating means for 
generating land object image data to display a 
land object; wherein 

said land object image data includes a program 
control code; 

said video game apparatus further comprising 
a program control code detecting means to de- 
tect the program control code in relation to a 
position of the player object, and a sound 
changing means to cause the sound signal to 
change according to the program control code 
- detected. 



7. A video game apparatus according to claim 1, 
wherein the program control code includes a cam- 
era control code, said image changing means in- 
cluding a camera control means to control a virtual 
camera provided in said three dimensional virtual 
space. 

8. A video game apparatus according to claim 7, 
wherein said virtual camera includes a plurality of 
virtual cameras, the camera control code including 
a camera switching code, and said camera control 
means including a camera switching means to 
switch between said plurality of virtual cameras de- 
pending upon the camera switching code. 

9. A video game apparatus according to claim 1, 
wherein the program control code includes a sound 
code, further comprising 

a sound data generating means to generate 
sound data, and 

a sound control means to control sound to be 
outputted from said sound data generating 
means depending upon the sound code. 

10. A video game according to claim 9, wherein said 
sound data generating means can generate sound 
data for a plurality of ones of sound, the sound code 
including a sound switching code and said sound 
control means including a sound switching means 
to switch the sound data depending upon the sound 
switching code. 



12. A memory medium applicable to a video game ap- 
paratus for generating, and supplying to a display, 
an image signal to display a player object existing 
on a land object in a virtual three dimensional space 
by processing image data for the player object and 
the land object according to a program, and mem- 
orized with a program to be processed by an infor- 
mation processing means included in said video 
game apparatus, said memory medium comprising: 

a player object image data generating program 
to generate player object image data for dis- 
playing a player object; and 
a land object image data generating program 
for generating land object image data to display 
a land object; wherein 

said land object image data includes a program 
control code; and further comprising 
a program control code detecting program for 
detecting the program control code in relation 
to a position of the player object, and an image 
changing program for causing said image sig- 
nal to change depending upon the program 
control code detected. 

13. A memory medium according to claim 12, wherein 
the program control code includes an action code 
to control an action of the player object, the image 
changing program including animation data output 
program for outputting animation data to automati- 
cally cause said player object to make an action de- 
pending upon the action code. 
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14. A memory medium according to claim 13, wherein 
the land object image data generating program gen- 
erates a land object of a hollow or hole and an action 
code of "jump", said animation data input program 
outputting animation data to cause said player ob- $ 
ject to make an action of jumping over the hollow or 
hole. 

15. A memory medium according to claim 14, wherein 
said video game apparatus has a controller, in as- to 
sociation therewith, including a direction instructing 
means to instruct a moving direction of the player 
object so that the player object is moved in the mov- 
ing direction, said memory medium further compris- 
ing 15 

a moving speed detecting program to detect a 
moving speed of the player object, and 
a jump distance calculating program to calcu- 
late a jump distance of the player object based 20 
on the moving speed, and 
said animation data output program outputting 
animation data to cause the player object to 
make an action of jump according to the jump 
distance. 25 



said land object image data generating means gen- 
erates a land object including a sound code of a pro- 
gram control code, further comprising 

a sound data generating program to generate 
sound data, and 

a sound control program to control sound to be 
outputted from said sound data generating 
means depending upon the sound code. 

21. A memory medium according to claim 20, wherein 
the sound data generating program can generate 
sound data of a plurality of ones of sound, the sound 
code including the sound switching code, and the 
sound control program including a sound switching 
program to switch the sound data depending upon 
the sound switching code. 



16. A memory medium according to claim 13, wherein 
the land object image data generating program gen- 
erates a land object of a wall surface and an action 
code of "climb", and said animation data output pro- 30 
gram outputting such animation data that said play- 
er object makes an action of climbing said wall sur- 
face. 

17. A memory medium according to claim 16, wherein 35 
when the action code is not "climb", a wall surface 
height calculating program is further comprised to 
calculate the wall surface height, 

the animation data output program outputting 
such animation data that the player object makes 40 
an optimal action depending upon the wall height. 



18. A memory medium according to claim 12, wherein 
the land object image data generating means gen- 
erates land object image data including a camera *s 
control code, and the image changing program in- 
cluding camera control program to control a virtual 
camera provided in the three dimensional virtual 
space. 

so 

19. A memory medium according to claim 18, wherein 
said virtual camera includes a plurality of virtual 
cameras, the camera control code including a cam- 
era switching code, and the camera control pro- 
gram including a camera switching program to 55 
switch between said plurality of virtual cameras. 



20. A memory medium according to claim 12, wherein 
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